March 24, 2000

Lucy, Lorna, Claude, Francois, Chris Barton, Manny, Andy Hook, James , Zhaoheng, Marek, Bob Donnovan, Charles, John Outerbridge, Chris Larnder, probably others

Manny took meeting notes

Lucy produced final document

The major efforts in the past development phase were:

• Definition of basic API, naming and coding conventions for the developmnent.
• C-API definition for both Collision and Karma
• Architecture design and implementation for collision and karma
• PS2 optimization
• Demo development for GDC
• User documentation (user guides and reference manuals) written from scratch
• Build and CVS organisation,
• Product installation and delivery

Past development phase could be characterised by ‘frantic coding’.

Lucy distributed a rough timeline chart of the main events and activities. (chart appended below).

Summary comments on timeline chart:

• The team assembled in mid-January.

• API conventions weren’t stable till mid February. This was a strain on development.

• There was a 911 release in Jan which meant that Russel had to deal with 2 clients (F1 group and GDC development).

• Kea branch in Jan: original C++ kea used by F1; new C-API started for GDC development.
• There were 2 parallel collision developments happening up to the end of January: Bryan’s game collision SDK and the collision team’s new architecture. These 2 architectures were synchronised during the last week in January when Bryan and John were in Montreal. After that the collision C-API was born and implemented during the following 2 weeks. The collision C-API was first available for use with usage docs (from Bryan) in mid-february. This was a remarkable feat that Bryan and the collision team pulled off. It was also a strain on the demo developers not getting collision so late in the day. And the PS2 version of collision wasn’t ready till end of February. Interface between collision and dynamics was also developed only just in time.
• All the user docs were written in only 4 weeks and there was no source material till the second week.

Almost everything that was delivered was entirely new code/architecture/docs and developed in an extremely short period of 6-8 weeks. The only thing that existed before January was Kea. Kea was stable which was a good starting point. Karma was new. Collision was new (even though a lot of the ideas in collision were carried over from the previous sdk). And Docs were new.

Manny summarised the effort: "You people did an amazing job, but don’t do it again".

These are the key activities that will characterise the next development phase:

• Alpha sites
• Customer support
• We will be getting feedback, bug reports and enhancement requests from alpha sites
• We’ll probably have to do intermediate bugfixes and a second alpha release.
• New development will include some of the following:
• Vehicle lib
• Particles
• SRB
• Cloth
• IVH
• Collision: convex, meshes, cylinders, and features to support all of the above.
• ME File format
• Stats, performance profiling, and file format for the ACME viewer
• Plugins
• SIGGRAPH demos

So aswell as a lot of design and development that needs to be done, we will also have to be supporting alpha sites, putting some propper QA in place and doing intermediate releases. This will necessarily change the development style considerably.

• The two strong components (dynamics and collision) were the resulting experience from several previous designs. A lot of the ideas in collision carried over from the (old) sdk. Kea was the result of both previous lateral logic experience and SDK1 experience. Re-architecting code seems to work.
• The demos could work because the technology was good.

• It really helped having many of the developers in one place. There was good communication (in the form of technology discussions) in Montreal because people were here. Much tutoring was going on from Russel and Claude. Similarly it really helped having Bryan and John for the one week in January so that the 2 collision architectures could be synchronised.

• It helps a lot when people are given the authority to make decisions and then do so. Delegation with empowerment works (John).

• Clear goals in Montreal.
• Having a fulltime buildmaster not only worked but was essential.
• Research demo organisation (Lorna) worked well.
• User documentation turned out very well considering it was done in 4 weeks only. Good source material was provided and a little bit of time for first reviews.

This section contains transcripts of the actual discussions which took place in the meeting, roughly organised into topics.

These are not decisions or group recommendations, most of the text below are simply quotes from the meeting. Some editing was done to clarify the context and to reduce repetition.

One thing that did not work was trying to do a release in a single day. The following events were expected to happen in one day:

• Code freeze
• Docs freeze
• Run Install scripts and last minute install fixes
• Release testing

Code and file and directory names were changing up to the very last minute.

Last minute changes did not break build.

But they do affect the docs.

Until December, fast dynamics SDK was what we were going to release at GDC.

Mayfly was also planned for this period – it was dropped very late in the game.

Even now we are not sure of the status of Mayfly – will it be developed further?

Russ passed ownership of PS2 Kea development to Richard and Karma team (James Golding, James French). Karma just emerged, not planned. Karma was just supposed to be simply a C++ wrapper on Kea. Whereas Mayfly was supposed to be a C++ wrapper that would wrap Featherstone, Kea, etc.

Particles were being done in Oxford. We didn’t have the bandwidth to get it in: feature review, evaluate, code review, integrate in karma.

Same with SRB. It got checked in the last week, but that was probably a mistake since we then had to keep it out of the release.

Having a buildmaster on site in Montreal was something that worked – it was essential.

Chris was there full time fixing the builds.

The build was breaking constantly since it was not easy for developers to test a change on multiple platforms. PS2 checkins broke PC and IRIX builds and vice-versa.

ChrisB - It wasn’t that bad. In fact working on 3 different platforms made it easier.

This phenomenon may not occur again – I.e. the basic architecture is now in place.

It happened for a few reasons:

• Kea source code was very clean, and the dynamics were stable.
• The two strong components (dynamics and collision) were the resulting experience from previous designs. A lot of the ideas in collision carried over from the (old) sdk. Kea was the result of both previous lateral logic experience and SDK1 experience.

• A lot of tutoring was going on. Russell was available. Everyone felt that they could change the code, because they could understand what it did. New features could go in without architecting or planning.

Communication was very difficult between offices. And sometimes even within an office.

Collision was scattered: Bryan in SF, and Ben was involved in PS2 port in Oxford (part time or late?). Ben had conflicting priorities: he was responsible for PS2 collision and he also had to deal with strategic demos in Oxford.

I had no idea that collision had to be released at GDC until a few days before GDC – Chris B.

Lorna: she had no communication problems.

Why was Koala low priority? it was checked in in the last week, but how does it plug into karma? It wasn’t low priority it was just that other stuff was higher priority – e.g. partitioning.

There was a discussion: do we need a separate single rigid body tool, or can Kea do it?

SRB was expected to be an important optimization. Not being articulated (bodies), it would be faster.

It overlaps with Kea—is the performance benefit clear.

Use cases: shrapnel. no collision

Bob was in agreement that SRB adds value. Bob wanted it in.

[Diagram]

Karma

/ | \

Kea, FastSRB, other solvers

On the topic of SRB and particles, Andy made the point that projects which have more visibility/advocacy are more likely to be adopted.

Perhaps an RFC would make it clear. As a user of the technology, I could look at an RFC and comment.

It wasn’t a question of SRB and particles not having enough advocacy. We were simply out of time. No time for writing nor even reading documents. In fact there were docs written but there still wasn’t time to evaluate them or integrate the technology, or to do integrated demos or documentation.

Russell did a lot of advocacy for Kea—a web site, etc. People bought into the product.

It just took someone to use it and find out that it was more stable (Chris B).

It had a visibility that made it easier to accept.

They didn’t buy in to Kea because of the website, the buy-in happened cos the technology was more stable and faster.

But it was agreed that visibility and documentation and communication is a ‘good thing’ during the design process.

Kea grew out of the Oxford experience. and out of the Montreal experience (911 etc).

Kea went through three stages of prototyping.

We had learned from 3 rigid body toolkits

This made clarity and optimization possible.

Every single line of Kea was rewritten in Jan and February.

If we want to repeat this success, we allow the time to do a couple of versions that we are going to scratch.

But in order to be competitive we also need to ship products with competitive features, the technology may change underneath but we need an API that is stable.

But if we bring out a much better product with many changes, people will be happy, justifying a changed API. We now have the experience so that we can do a total rewrite.

Bob brought people over from Oxford to help with the GDC development.

And Oxford developers will also be needed for the next development phase.

Buildmaster was critically important.

Documentation worked out really well.

4 weeks from the day Manny started. No source material for first week, just old stuff to read.

People finally started providing source material.

In the last week Manny couldn't process all the information he was getting fast enough.

There were complaints about using Framemaker for the user docs, since developers do not have framemaker. Also a problem merging changes since frame files are binary.

We want to be able to go into the docs, make small changes publishable, visible. If there is a module that is broken, you can go in and fix it: docs should be the same.

A problem in the doc was a big hassle, we had to wait until Manny returned to do the fix.

Counter-argument:

Ownership is the norm in software. There are many modules that need the owner to do the fix since they are the only ones that understand the code.

In documentation or source code, you can’t expect everyone to go in and fix any bug.

We can use bug tracking to manage documentation bugs, same as sw bugs.

We need the sense to not go in fix stuff that we don’t know about.

But for a tiny bug in SW or docs it should be easy for anyone to fix.

This shouldn’t be stopped because of tool-inaccessibility.

Everything should be allowed.

A flexible process, with rules on top.

John: We haven’t explored Frame on Linux.

Marek: problem with merging binary files (in CVS). He likes open source projects – you have it driven by one team, but every can see it.

LaTeX is not like Word. It can do everything that Frame can do. But it has no GUI.

The problem is that running diffs on LaTeX is really ugly.

Everyone should be able to go into the root page.

The intranet is so valuable, everyone needs access.

Everything should be in CVS.

Someone should be responsible.

Processes should work even if people aren't there. (Andy)

Idea was promoted by Lucy, rejected by Andy.

CVS Good -- Peer reviews bad. (Manny's summary of Andy's position)

Suggestion: a core group may reject submissions.